System and method for generating user interfaces for different instrument types

ABSTRACT

An instrumentation interface application that obtains information from an instrument directory and generates a graphic user interface populated based on the information. The information for a given instrument may be formatted in a manner so as to allow the interface application to interpret the information to be displayed in a certain manner. By delegating the such details of the instrument information to a directory instead of the interface application, the interface application can be utilized more effectively for relatively large biological laboratories that have many instruments of different types. The graphic user interface generated in such a manner can be used to monitor and control a variety of different aspects of the laboratory, including instrument management, sample management, and study-related management.

CLAIM OF PRIORITY

[0001] This U.S. patent application claims priority to U.S. ProvisionalPatent Application No. 60/386,296 entitled “Informatics SystemArchitecture” filed Jun. 4, 2002 and U.S. Provisional Patent ApplicationNo. 60/411,574 entitled “Integration Instructions For Informatics SystemArchitecture” filed Sep. 16, 2002 which are hereby incorporated byreference. Additionally, this application relates to the followingco-pending applications filed on the same date which are herebyincorporated by reference in their entirety: attorney docket numberABIOS.044A entitled “System And Method For Open Control And MonitoringOf Biological Instruments”, attorney docket number ABIOS.045A entitled“System And Method For Discovery Of Biological Instruments”, andattorney docket number ABIOS.046A entitled “System And Method ForProviding A Standardized State Interface For Instrumentation”.

BACKGROUND

[0002] 1. Field

[0003] The present teachings generally relate to a system and methodsfor interacting with components used in laboratory environment and moreparticularly to a coordination schema and dynamically generated userinterface for monitoring, coordinating, and controlling components andinstrumentation.

[0004] 2. Description of the Related Art

[0005] Biological laboratories, in particular those focused on geneticand molecular biological work, generally employ a wide variety ofinstrumentation and applications, the activities of which must becoordinated in order to conduct experiments and analysis. A selectedanalysis may require the use of numerous instruments including, forexample, an electrophoresis component, a thermalcycler, a massspectrometer, and/or a gene sequencer. To further complicate matters,some assays and high throughput approaches require the manipulation ofhundreds, if not thousands, of samples, each of which must be processedthrough a multiplicity of tests, the collected data from which must thenbe analyzed by secondary analytical instrumentation and applicationsbefore generating the desired result. In addition, the physical andlogistical demands of the laboratory increasingly utilize robotics aswell as human investigators in order to locate and deliver samples tothe proper instrumentation.

[0006] Communication complexity in the laboratory environment representsanother area of potential inefficiency where problems may arise. Eachinstrument, robot, hardware and/or software application generally hasinput and output parameters/information which must be properlyconfigured/accessed in order to be utilized. This information mayinclude machine or application specific experimental parameters,commands, and/or catalog information. A particular limitation of manyconventional systems is that not all biological instruments/applicationsare designed to communicate readily with each other and, as aconsequence, human intervention is frequently required to coordinate theactivities of each instrument and application. In many instances, acentralized information flow control system would be desirable in orderto reduce human intervention and errors. However, because a givenlaboratory environment may contain many differentinstruments/applications, produced by different manufacturers withdifferent requirements and input/output data types, it is difficult tointegrate conventional instrument platforms into a unified system.Furthermore, as new instruments/applications are introduced into thelaboratory environment with existing systems, additional difficultiesmay be encountered arising from configuration limitations associatedwith previous laboratory setups. A still further drawback found in manyconventional systems is that a common user interface for monitoring orcontrolling each of the instruments/applications in the laboratoryenvironment is not available. As a consequence, certaininstruments/applications must be monitored and controlled separatelyfrom other laboratory components resulting in a less desirabledecentralized system architecture.

SUMMARY

[0007] One aspect of the present teachings relates to a system forproviding a centralized user interface for a biological laboratoryhaving a plurality of biological processing instruments adapted toprocess a plurality of biological samples. The system comprises aninformation component for instruments that includes information aboutthe plurality of the biological processing instruments. The informationfor a given instrument comprises a list of the instrument's parametersthat can be monitored and a list of the instrument's parameters that canbe controlled. The system further comprises an interface applicationthat generates the graphic user interface based on the information forone or more of the instruments. The interface thus generated ispopulated according to at least a portion of the instrument's monitorand control parameters thereby allowing the interface application togenerate different interfaces based on a single adaptable templateinterface.

[0008] In certain embodiments, the centralized user interface for agiven instrument allows a user to monitor and control the instrument. Inone of such embodiment, the interface application uses the informationabout the plurality of instruments to generate an instrument managementgraphic user interface that lists instruments available for use.

[0009] In certain embodiments, the system further comprises aninformation component for samples that includes information about theplurality of biological samples. The samples' information componentallows the interface application to generate adaptable user interfacesbased on the samples' information. In one of such embodiments, theinterface application uses the information about the plurality ofbiological samples to generate a sample management user interface thatlists the samples in the biological laboratory. In one of suchembodiments, the sample and instrument information are combined to allowthe interface application to generate a study management user interface.Such user interface is adapted to allow a user to plan a manner in whichdata is taken during a run.

[0010] In certain embodiments, the system further comprises aninformation component for an analysis module that analyzes the data fromone or more biological processing instruments. The analysis module'sinformation component allows the interface application to generateadaptable graphic user interfaces based for viewing results of theanalyzed data.

[0011] In certain embodiments, the plurality of biological processinginstruments includes any combination of a sample storage device, asample transferring robotics device, a thermalcycler device, a massspectrometer, a sequencer device, an electrophoresis device, an arraydevice, an analysis computing device, and a data storage device. Incertain embodiments, the instrument component is part of an instrumentdirectory.

[0012] Another aspect of the present teachings relates to a method forgenerating a centralized user interface for a biological laboratoryhaving a plurality of biological processing instruments adapted toprocess a plurality of biological samples. The method comprisesreceiving a request for a selected user interface; obtaining informationassociated with the requested user interface; and generating therequested user interface by populating a template user interface basedon the information obtained.

[0013] In certain implementations of the method, receiving the requestcomprises receiving a request for a user interface for one or morebiological processing instruments. In one of such implementations,obtaining information comprises obtaining information about the one ormore biological processing instruments from an instrument directory.

[0014] In certain implementations of the method, receiving the requestcomprises receiving a request for a user interface for one or morebiological samples. In one of such implementations, obtaininginformation comprises obtaining information about the one or morebiological samples from a sample list.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015]FIG. 1 illustrates an exemplary biological laboratory having aplurality of biological processing instruments that can be monitored andcontrolled by a user interface;

[0016] FIGS. 2-1 to 2-5 illustrate how various instruments can beintegrated so as to be recognized by a control system;

[0017]FIG. 3 illustrates various functional features of the biologicallaboratory that can be represented by the user interface;

[0018]FIG. 4A illustrates a graphic user interface (GUI) applicationthat generates a GUI for a particular instrument based on informationabout that instrument, wherein the generated GUI is based on a commontemplate GUI;

[0019]FIG. 4B illustrates a web browser that could be used as a userinterface;

[0020]FIG. 4C illustrates a dynamic generation of an instrument-relatedGUI when a new instrument is added to the system;

[0021]FIG. 5A illustrates an exemplary instrument information that canbe used for generating the GUI for the exemplary instrument;

[0022]FIG. 5B illustrates an exemplary GUI for monitoring the instrumentof FIG. 5A;

[0023]FIG. 5C illustrates an exemplary GUI for controlling theinstrument of FIG. 5A;

[0024]FIG. 6 illustrates an exemplary GUI for monitoring a list ofsamples;

[0025] FIGS. 7A-C illustrate exemplary GUIs that can be generated frominstrument and/or sample information, thereby allowing representationsof instrument and/or study management features;

[0026] FIGS. 8A-B illustrate exemplary GUIs that can be generated todisplay either raw data as they come out of instrument(s);

[0027]FIG. 9 illustrates an exemplary GUI that can be generated todisplay an analyzed data;

[0028]FIG. 10 illustrates a process that generates a GUI based on theavailable information;

[0029]FIG. 11 illustrates a communication sequence and functionalitiesof a dynamic container creation service;

[0030]FIG. 12 illustrates a sample snapshot from a data collectioninstrument;

[0031]FIG. 13 illustrates a custom client that may use an exemplaryfunction subscribeInstrumentEvents( ) to prepare itself to receiveinformation from exemplary ICFStatusEvents( ) andICFContainerStatusEvents( ) functions;

[0032]FIG. 14 illustrates an exemplary flowchart that describes onepossible implementation of a pulling and pushing process;

[0033]FIG. 15 illustrates how a custom client can “push” containerinformation to a service provider to persist in the service provider'sdatabase allowing it to be run at a later time;

[0034] FIGS. 16-20 illustrate various embodiments of XML schema forapplication and container definitions that may be used in implementationof service sets and container creation/utilization services; and

[0035]FIG. 21 illustrates one method for implementing a web-browserbased dynamically loaded user interface implemented using the JAVAlanguage.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

[0036] These and other aspects, advantages, and novel features of thepresent teachings will become apparent upon reading the followingdetailed description and upon reference to the accompanying drawings. Inthe drawings, similar elements have similar reference numerals.

[0037] One aspect of the present teachings relates to a user interfacesystem (UI) that provides means for a user to interact with a pluralityof instruments and applications. The user interface system furtherfacilitates monitoring and controlling of the instruments/applicationsin a centralized and a user-friendly graphical environment. FIG. 1illustrates a functional block diagram showing a system for biologicalanalysis 1000 wherein an application programming interface (API) 1032provides communication functionality between a user interface 1034 andseveral possible types of instruments 1002 associated with biologicalanalysis. Such instruments may include, by way example, one or moresample storage devices 1010; one or more sample transfer roboticsdevices 1012; one or more sample multiplexing devices (e.g., athermalcycler 1014); one or more sample analyzing devices such as a massspectrometer 1016, a sequencer 1020, an electrophoresis device 1022, anarray analysis device 1024; one or more analysis computing devices 1026;and one or more data storage devices 1030. In one aspect, the interface1032 is configured to generate a user interface (UI) 1034 thatfacilitates the user's interaction with the exemplary instrument(s)described above. More specific examples of these instruments aredescribed below in the form of examples.

[0038] It will be appreciated that any type of instruments notillustrated in FIG. 1 may be included in the analytical system withoutdeparting from the spirit of the present teachings. Moreover, thepresence of the type(s) of instruments as illustrated in FIG. 1 does notnecessarily mean that such a instrument is required in the analyticalsystem.

[0039] In one aspect, the interface 1032 advantageously can beconfigured to provide a common graphical user interface (GUI) thatdynamically adapts to the various parameters associated with theinstruments. The interface 1032 may obtain the parameters for a giveninstrument in a manner described below. By delegating the details aboutthe instruments to some database, the GUI formation may be greatlysimplified since the user does not need to worry about the specifics ofthe instruments in configuring the application that generates the GUI.

[0040] In one aspect, dynamic generation of the user interface isaccomplished in such a manner so as to simplify its creation byutilizing database-stored instrument and application definitionsdetailing input/output requirements for each type or class of instrumentand application. This information is automatically associated with theappropriate field of the user interface thereby facilitating itsgeneration and freeing the user from having to know extensive details ofthe I/O requirements of each instrument/application while still allowingfor relatively simple construction/configuration of the user interface.

[0041]FIG. 1 also illustrates a sample 1004 being processed by theaforementioned exemplary instruments. The sample may be identified inany number of ways, including for example, a barcode or other uniqueidentifier 1006. As described below in greater detail, a plurality ofsuch samples may be managed via the interface 1032 in conjunction withthe plurality of exemplary instruments.

[0042] Furthermore, FIG. 1 also depicts the exemplary instruments havinga physical portion and a programmatic portion. The programmatic portionmay represent, for example, one or more processes that may be running inthe instrument. The physical portion may represent the actual hardwareportion of the instrument. As FIG. 1 illustrates, the programmaticportions of the analysis-related instruments (exemplified as thethermalcycler 1014, mass spectrometer 1016, sequence 1020,electrophoresis 1022, and array 1024) may also be functionally coupledto the analysis computing device 1026 such that data can be passedtherebetween and be processed remotely from the instrumentation. Thecomputer 1026 may be functionally connected to the data storage devices1030 so as to allow the computer 1026 to store and/or retrieve datatherefrom. In certain embodiments, the data storage device 1030 may alsobe accessed by the instruments directly so as to store and/or retrievedata without requisite interaction by the computer 1026. The instrumentsand computing-related components arranged in the foregoing manners arerepresentative of various configurations which allow biologicalmeasurements and analysis to be conducted using a centralizedcoordination system through which an investigator interacts using theuser interface.

[0043] In general, it will be appreciated that the processors maycomprise, by way of example, computers, program logic, or othersubstrate configurations representing data and instructions, whichoperate as described herein. In other embodiments, the processors cancomprise controller circuitry, processor circuitry, processors, generalpurpose single-chip or multi-chip microprocessors, digital signalprocessors, embedded microprocessors, microcontrollers and the like.

[0044] Furthermore, it will be appreciated that in one embodiment, theprogram logic may advantageously be implemented as one or morecomponents. The components may advantageously be configured to executeon one or more processors. The components include, but are not limitedto, software or hardware components, modules such as software modules,object-oriented software components, class components and taskcomponents, processes methods, functions, attributes, procedures,subroutines, segments of program code, drivers, firmware, microcode,circuitry, data, databases, data structures, tables, arrays, andvariables.

[0045] FIGS. 2-1 to 2-5 illustrate a manner in which various devices canbe integrated into a laboratory system. Such an advantageous manner isdescribed in greater detail in a copending application titled “Systemand Method for Open Control and Monitoring of Biological Instruments,”attorney docket number ABIOS.044A, which is hereby incorporated byreference in its entirety.

[0046]FIG. 2-1 illustrates an integration framework of a biologicallaboratory system having a plurality of exemplary devices indicated as arobot 2-130, an electrophoresis device 2-134, a sample amplificationcomponent 2-136, a mass spectrometer 2-138, an analysis computer 2-142,and a thermalcycler 2-144. Such devices may be connected to a commonnetwork, and be managed by a management system 2-104 via the commonnetwork. The management of the devices may be facilitated by aninstrument directory 2-112 that includes information about the devices.Such information may include the types of interfaces supported by thedevices, device-specific information such as serial number and physicallocation, and identifiers that allow communication via the network. Incertain embodiments, the instrument directory 2-112 also includes a listof updated devices that are available for use.

[0047] The management of the devices may also be facilitated by aninstrument-type server 2-114. In certain embodiments, theinstrument-type server 2-114 provides the management system 2-104 withinformation about various devices' requirements so that the managementsystem 2-104 can monitor and control the devices in an appropriatemanner.

[0048] The management of the devices may also be facilitated by amessaging service 2-118. The messaging service 2-118 allowscommunication between the various management-related entities (e.g.,management system, instrument directory, instrument-type server, andother entities described below), various devices, and other entities inthe laboratory system. In certain embodiments, the messaging service2-118 provides such communication without having to rely on a directcommunication between components.

[0049] The management of the devices may also be facilitated by aninstrument control component 2-122. In certain embodiments, theinstrument control component 2-122 comprises a computing deviceconfigured to run service provider software or applications 2-123. Suchsoftware may be configured to provide control over the devices as wellas provide devices' status updates to the management system 2-104. Incertain embodiments, the service provider software 2-123 may implementone or more software interfaces that allow communication between themanagement-related components with the various devices in a meaningfulmanner.

[0050] The management of certain devices in the laboratory system mayalso be facilitated by networking/service computers (indicated as 2-132and 2-140 in FIG. 2-1). Such computers may provide improvedcommunication with devices that do not have their own networking andcommunication capabilities. Thus, the networking/service computersemulate the desired networking and communication functionality for theirrespective devices.

[0051]FIG. 2-2 illustrates one possible routing of communication betweena client 2-240 and a plurality of exemplary devices (2-210, 2-215,2-220, 2-225, and 2-230). The client 2-240 entity may include themanagement system described above in reference to FIG. 2-1. In theexemplary communication scheme of FIG. 2-2, an instrument directory2-245 provides the client 2-240 with information about the devices.Then, the communication between the client 2-240 and the device(s) isfacilitated via a messaging service 2-205. The messaging service 2-205may rely on an instrument-type service provider 2-250 to format thecommunication according to the devices' requirements.

[0052] FIGS. 2-3A and 2-3B illustrate two possible modes ofcommunication between the various components. In a point-to-pointmethod, a communication between a client and a device is performed in agenerally chained manner. In an exemplary chain, a message from theclient goes through a messaging service, through an instrument software,and then to the destination device (instrument hardware in FIG. 2-3A).

[0053]FIG. 2-3B illustrates a publish/subscribe messaging method. In anexemplary communication where the device wants to send a message to theclient, the device sends a status signal to the service provider that inresponse publishes that status (along with an appropriate topic) to themessaging service. The messaging service does not automatically relaythe status message to the client. Instead, the client subscribes to themessaging service with an appropriate topic. The messaging servicematches the topic from the instrument software with that from theclient, and sends the corresponding status message to the client.

[0054]FIG. 2-4 illustrates an exemplary instrument directory 2-405. Sucha directory may include an instrument information 2-425 that containsinformation such as instrument name, physical location, type, group,publishing information, and other information useful for management ofthe instrument (device). The directory 2-405 may also include aninstrument type provider information 2-440 that contains informationabout the instrument-type service provider described above in referenceto FIGS. 2-1 and 2-2. The directory 2-405 may also include a list 2-430of active instruments. The directory 2-405 may also include a storagedevice for storing information that facilitates various functions of thedirectory. The directory 2-405 is also shown to be connected to anetwork 2-415 so as to allow communication with other components.

[0055]FIG. 2-5 illustrates a possible functional relationship between aninstrument hardware 2-510 and an instrument service provider 2-505(described above in reference to FIG. 2-1). The hardware is depicted tobe in communication with a networking and service middleware 2-515. Suchmiddleware may be an integral part of the instrument, or may be anemulating component (networking and service computer in FIG. 2-1). Themiddleware 2-515 is in communication with other networked components viaa network 2-508. The instrument service provider 2-505, also networkedwith the middleware 2-515, may include a plurality of functionalities,including a state model component 2-530 and a hardware commandscomponent 2540. Various aspects of the state model component and thehardware command component are described below in greater detail.

[0056] From the brief description of the integration framework inreference to FIGS. 2-1 to 2-5, it will be appreciated that the presentteachings may be implemented in such a framework in a number of ways.For example, entities described herein as “translators” may beincorporated as part of the instrument service provider (FIG. 2-5).Similarly, entities described herein as “translations” may be part ofthe instrument interface (FIG. 2-4). It should be understood, however,that the various aspects of the present teachings may be implemented insystems other than that of the aforementioned framework withoutdeparting from the spirit of the present teachings.

[0057] As described above, the instruments can be advantageouslyintegrated and recognized via an instrument directory. As will bedescribed below, such a directory having information about theinstruments allows the interface (1032 in FIG. 1) to advantageouslyprovide an adaptable GUI for a given instrument.

[0058]FIG. 3 illustrates how the user interface 1032 can be constructedto provide access to a variety of assay-related monitoring informationand/or controls by including an instrument-interface capability, alongwith similarly common interfaces for samples, analysis, and otherstudy-related features. The exemplary monitor and/or control featuresare depicted as being categorized as either relating to laboratorymanagement functions 1042 or to study management functions 1044.

[0059] The laboratory management functions 1042 may comprise aninstrument management function 1046 and a sample management function1050. The instrument management function 1046 may comprise amonitor/control function 1060, a diagnostic function 1062, and acalibration function 1064. The sample management function 1050 maycomprise an inventory function 1066 and a sample tracking function 1070.

[0060] The study management function 1044 may comprises a run planningfunction 1052, a data run function 1054, and an analysis function 1056.The run planning function 1052 may comprise a standard run function 1072and a customized run function 1074. The data run function 1054 maycomprise a monitoring function 1076 and an online analysis function1080. The analysis function 1056 may comprise a detailed analysisfunction 1082 and a simulation function 1084.

[0061] It will be appreciated that the aforementioned exemplaryfunctionalities of an assay may be represented to the user in the formof a GUI for informational and/or control purposes. By having thedetails of the underlying features such as instruments, samples, runplanning, and analysis stored in accessible manner at some functionallocation, the application that generates the GUIs can be configured togenerate a GUI that adapts and populates itself according to thespecifics of a given feature. It will be appreciated that such acommonality of user interface improves the manner in which thebiological laboratory can be managed in general.

[0062] In the description below, the common GUI adapting to a variety ofunderlying features is described in terms of instruments. It will beunderstood, however, that similar concepts may be implemented formanaging samples and other assay-related features without departing fromthe spirit of the present teachings.

[0063]FIG. 4A now illustrates a GUI application 1090 configured togenerate a GUI. In one aspect of the present teachings, the application1090 is configured to generate a common GUI that can be populated withparticulars depending on the details of an instrument being interfacedwith. Such common GUI (also referred to as a template GUI 1098) may bemade accessible for the application 1090 to populate appropriately togenerate the desired GUI.

[0064] Thus, the application 1090 generates a GUI 1092 for an instrumentX 1104 based on available information 1100 for the instrument X.Similarly, the application 1090 generates a GUI 1094 for an instrument Y1106 based on available information 1102 for the instrument Y. Suchone-to-one relationship between a GUI and an instrument may be extendedto any number of instruments.

[0065] As shown in FIG. 4A, the information 1100, 1102 about theexemplary instruments X and Y 1104, 1106 may be functionally located ina database 1096 that includes instrument information 1096. Suchinstrument information database is described below in greater detail inthe form of an example.

[0066] As further shown in FIG. 4A, the application 1090 obtains theinformation 1100, 1102 for the exemplary instruments X and Y 1104, 1106and generates the GUIs 1092,1094 for X and Y, thereby allowing the userto monitor and/or control the instruments X and Y 1104, 1106. In certainembodiments, the interaction between the GUIs and the instruments may beperformed via the application 1090. Alternatively, the GUIs may beconfigured to bypass the application and interact directly with theinstruments. In either of these two alternatives, the interaction may beeither directly or via a controller 1108.

[0067]FIG. 4B illustrates that in certain embodiments, a user interfaceapplication 1214 may be configured to launch user interfaces 1222. Suchinterfaces may comprise a GUI 1224, a web browser based user interface1226, or any combination thereof. The use of web browsers as a basis forthe user interface may be advantageous in certain platforms that supportthe user interface application 1214. In certain embodiments, such webbrowsers may be implemented using the HTML code known in the art.

[0068] The user interface application 1214 may populate the GUI 1224and/or the web browser 1226 using information obtained from aninformation source such as an instrument directory 1210 in a mannersimilar to that described above in reference to FIG. 4A. The directory1210 is depicted to include available information 1212 for a pluralityof exemplary instruments 1216 “X1” “X2,” etc. Also similar to theconfiguration of FIG. 4A, the interaction between the instruments 1216and the user interface application 1214 may be either directly or via acontroller 1220.

[0069]FIG. 4C illustrates a system 1240 of certain embodimentsconfigured to dynamically generate a GUI 1254 when an exemplaryinstrument (denoted as “YY”) 1242 is added to the system 1240. Adirectory 1246 may be updated with information 1250 about the instrument“YY” 1242 in a manner described above. Such updating of the directory1246 may be facilitated by a management system 1244.

[0070] The addition of the instrument “YY” 1242 to the system 1240 maycause the management system 1244 to discover the instrument “YY” 1242 ina variety of ways. For example, the management system 1244 may routinelycheck the directory 1246 and note the additional entry. In anotherexample, the addition of the instrument's information 1250 in thedirectory may be accompanied by a broadcast to the system 1240,informing the system 1240 of the addition.

[0071] The management system 1244 may be configured such that upon suchdetection of an added instrument, it may invoke a GUI application 1252to launch a GUI 1254. The GUI 1254 generated in such a manner mayinclude the instrument's available protocol as well as other featuresthat facilitate the sample assay process. The GUI application 1252 maybe configured to generate the GUI 1254 by populating a common templateGUI, based on information 1250 for the instrument “YY” 1242, in a mannersimilar to that described above in reference to FIG. 4A. Thus, one cansee that such a functionality allows a user to add a compatibleinstrument to the system 1240 and be provided with a visual interfacethat aids in incorporating the added instrument into an assay process.

[0072] FIGS. 5A-C illustrate an exemplary instrument information 1112and its corresponding GUIs 1114 and 1120 that may be generated by theapplication 1090 described above. The exemplary instrument information1112 may be part of an instrument directory 1110. The instrumentdirectory is described above in reference to the system framework.

[0073] As shown in the instrument information 1112, the exemplaryinformation may comprise an instrument identifier. In the exemplaryinformation, the instrument is designated as “A” that represents anarray device. The information further comprises available monitorparameters and available control parameters for the array device.

[0074] The exemplary available monitor device may comprise theparameters listed in FIG. 5A. As shown in FIG. 5B, such parameterspopulate the GUI 1114 by the application 1090. In certain embodiments,the order of parameters in the information 1112 may determine the mannerin which the they are arranged on the GUI 1114. Additionalsub-parameters associated with the parameters may also determine how theparameters are displayed on the GUI 1114. For example, exemplaryparameters numbered as 15 to 20 have associated with them a series ofinput values to be interpreted in the following exemplary manner: firstsub-parameter is the unit; second and third sub-parameters are the lowerand upper limits for actual value (fourth sub-parameter) and set/nominalvalue (fifth sub-parameter). Thus, for the exemplary parameter “EPVoltage,” the unit to be displayed is “KV,” and the lower and upperlimits of a scale to be displayed are 0 and 15 KV, respectively. Thefourth sub-parameter of “EP_V_actual” is a value of the actual voltageof instrument “A” 1116 (1.0 KV in the exemplary GUI of FIG. 5B). Thefifth sub-parameter of “EP_V_set” is a value of the set voltage for theinstrument 1116 (3.0 KV in the GUI of FIG. 5B).

[0075] The ranges of parameter values in the foregoing example may beformatted so as to instruct the application to display them in a certainmanner. It will be appreciated that there are many number of waysinformation can be displayed on a GUI. It will be further appreciatedthat the information for instruments may be formatted in any number ofways to provide any number of display formats of the GUIs withoutdeparting from the spirit of the present teachings.

[0076]FIG. 5C illustrates an exemplary GUI 1120 launched by theapplication 1090 based on the information 1112. The exemplary availablecontrol parameters may comprise a laser operation and a commentfunction. The laser function may be formatted in the following exemplarymanner: first sub-parameter is the unit; second and third sub-parametersare the lower and upper limits to be displayed proximate a fourthsub-parameter of a user input value. The laser function may comprise oneof the following exemplary choices: “Set Power”; “Apply Power”; and“Shut Down.” As previously described, in certain embodiments, the mannerin which the control parameters are displayed may be determined by theformat of the listed control parameters. In the exemplary GUI 1120described above, the one or more control commands selected through theGUI may be sent to the exemplary instrument 1116.

[0077]FIG. 6 now illustrates an exemplary GUI 1130 launched by theapplication 1090 based on a sample list 1132. The sample list 1132 couldbe considered to be a similar “information” about the samples analogousto the instrument information described above. The sample list 1132could contain information about the inventory of substantially all thesamples within the system, or about the whereabouts of a particularsample. The sample list 1132 could be facilitated by thesample-identifying means such as the barcode 1006 described above inreference to FIG. 1.

[0078] FIGS. 7A-C now illustrates some exemplary GUIs that may belaunched by the application 1090 based on some combination of instrumentinformation and sample information. Such combination of information canfacilitate the various laboratory and study management functionsdescribed above in reference to FIG. 3.

[0079]FIG. 7A illustrates an exemplary GUI 1140 that may be launched bythe application 1090 based on the collection of instruments' information(1096 in FIG. 4A). In particular, the exemplary GUI 1140 is configuredto list instruments that may be used with a particular type of anexemplary activity (“Aliquot DNA”) with a particular type of anexemplary assay process (“ProcessRun02”). As shown in FIG. 7A, the GUI1140 can also list instruments associated with other exemplaryactivities “Sample Setup” and “Perform PCR,” with their respectiveexemplary processes “ProcessRun01” and “ProcessRun03.”

[0080]FIG. 7B illustrates an exemplary GUI 1142 that may be launched bythe application 1090 based on information provided by an activitymanager 1144. The activity manager 1144 may be a process or a databasethat combines information from the sample list 1132 and the instrumentinformation 1096. The exemplary GUI 1142 lists the samples(“C1234567890”) that are to be processed for the exemplary activity“Aliquot DNA” via the exemplary process “ProcessRun02.”

[0081]FIG. 7C illustrates an exemplary GUI 1146 that may be launched bythe application 1090 based on information provided by a run scheduler1150. The run scheduler 1150 may be a process or a database thatcombines information from the sample list 1132 and the instrumentinformation 1096 to schedule processing of the samples via the availableinstruments for one or more types of data-taking runs. As shown in FIG.7C, the particular GUI 1146 lists runs to be performed by an exemplaryinstrument “3100test1.”

[0082] It will be appreciated that the various exemplary GUIs describedabove in reference to FIGS. 5-7 can be considered to be variouspopulated form of a single GUI launched by the application 1090. Thevarious populations are based on the instrument and/or sampleinformation stored in a database separate from the application thatprovides the interface with the user. The information provided to theapplication may be processed by some intermediate process or databasesuch as the exemplary activity manager (1144 in FIG. 7B) and the runscheduler (1150 in FIG. 7C). In either of these two cases, however, theinformation provided to the GUI application 1090 is generally storedseparately from the application 1090, and can be considered to beanother form of database on which the GUIs are based upon.

[0083] This concept of providing the GUI application with informationfor the adaptive populating GUI can be extended to data presentation.FIG. 8A illustrates an exemplary GUI 1160 displaying a raw data from aninstrument “my3100.” The exemplary GUI 1160 may be launched by theapplication 1090 based on the instrument information 1096 thatcorresponds to an instrument 1162. In particular, the instrument 1162comprises the instrument “my3100.”

[0084] The raw data displaying GUI 1160 displays the data as it is beingoutput from the instrument 1162. As previously described, the manner inwhich the GUI display a given parameter could be determined by theformat of the parameter in the instrument's information. Thus, theexemplary raw data parameter could be formatted so as to make theapplication 1096 interpret the raw data output from the instrument 1162as a streaming graph-format display.

[0085]FIG. 8B illustrates another exemplary data-displaying GUI 1170that may be launched by the application 1090 based on the data from anexemplary instrument “kaitwo” 1172. Information about such an instrumentmay be obtained from the instrument information 1096. The informationabout the instrument 1172 may include an output data format that allowsthe GUI 1170 to display the data in a two-dimensional “Gel display”format.

[0086]FIG. 9 illustrates another exemplary data-displaying GUI 1180 thatmay be launched by the application 1090 based on the data output from ananalysis module 1182. In certain embodiments, the analysis modules thatprocess the data from the instruments could be treated like theinstruments in terms of integration and being listed in some form of adirectory. That is, the analysis modules could be listed in a databasesimilar to the instrument directory described above. Such a databasecould also list each analysis module's available outputs.

[0087] Thus, the exemplary GUI 1180 displays a post-instrument(s)processed data from the analysis module 1182. The analysis module 1182can also output the processed data to a result database 1184 for laterGUI display and/or other form or presentation.

[0088] The various exemplary GUIs described above can be generalized asbeing a single or a few GUIs that can be populated by informationobtained from some source accessible by the application that generatesthe GUI. In certain embodiments, the application generates a single GUIthat adapts to the various information.

[0089]FIG. 10 now illustrates a process 1190 for generating theaforementioned GUIs. The process 1190 may be performed by the GUIapplication 1090. The process 1190 begins as a start step 1192, and instep 1194 that follows, the process 1190 receives a request for a userinterface. Such a request may originate from an existing GUI. Forexample, a user may request additional information about the instrumentmanagement (1046 in FIG. 3) from an existing GUI that displays the labmanagement summary 1042. Similarly, the user may request an additionalinformation on a particular instrument from the thus-created GUI (ofinstrument management 1046), thereby creating the monitor/controlfunctionality 1060 GUI.

[0090] In step 1196 that follows, the process 1190 obtains informationassociated with the user interface. In step 1200 that follows, theprocess 1190 generates a GUI populated with the information obtained.The process 1190 ends at a stop step 1202.

[0091] Control And Management Services

[0092] In one aspect, the present teachings define a set of services(e.g. instrument and applications services) that are commonly supportedwithin the LIMS system. These services desirably aid in control andmanagement simplification across different instrument and applicationplatforms and facilitate integration of these components into theunified framework of the LIMS system.

[0093] In various embodiments, the service sets provide means forcontrol and monitoring of various components, including instruments andapplications, within the LIMS environment. Additionally, these servicesets may be desirably configured to enable remote connectivity via anetwork or other communication means. In general, components of the LIMSsystem may desirably implement a standardized instrument or applicationservice interface thereby providing a consistent set of interfaces whichfacilitate component integration into the LIMS system. In instanceswhere an interface may not be applicable to a certain component,instrument, or application type, the component may recognize andindicate that the interface is not-applicable.

[0094] In one aspect, the design and implementation of the componentapplication programming interface(s) (API) provide a framework ofcommonality in which a user interface (GUI) may be implemented on thebasis of an instrument services contract. Implementation in this mannermay be substantially independent of any instrument specifics while stillbeing able to control and monitor a selected component configured toutilize the service set.

[0095] The following description details various aspects of the servicesets and provides examples of how these services may be implemented inthe LIMS system. These functionalities are meant to illustrate possibleconfigurations which may be utilized by the LIMS system and should notbe construed to limit its functionality.

[0096] In one aspect, a service set may comprise a dynamic containercreation service. FIG. 11 illustrates the communication sequence andfunctionalities of the dynamic container creation service 1500. In oneaspect the dynamic container creation service 1500 functions to provideapplication dependent container type information. The type ofinformation that is gathered for each container typically depends onanalysis application or instrument. In one exemplary application, whenthere was a new type of analysis application is made available which isto be desirably integrated into the system, other applications, such asdata collection software, may need to be adjusted or modified to supportthe new analysis application. One feature of the dynamic containercreation service 1500 is it that it provides support for “plug-in”integration such that client applications and instruments candynamically gather information from a container type service provider,such as an analysis application, and dynamically construct a containereditor 1505.

[0097] In one aspect each instrument services service provider mayprovide an application installer 1510 that registers a selectedapplication for a particular instrument type. However, the serviceprovider need not be the sole provider for this information. As anexample, a selected instrument (e.g. sequencer) may populate a set ofapplications (e.g., a default fragment analysis application). If a newanalysis application is created for the instrument platform, anapplication installer 1510 can be provided that utilizes the existingset of attributes independent of the instrument itself.

[0098] In one aspect, the instrument services provide an interfaceimplementation for an application installer to register applicationspecific container 1520 and sample definitions, an example of which isshown below:

[0099] ICFResult ICFRegisterContainerParameters(StringcontainerDefinition) 1530;

[0100] ICFResult ICFRegisterApplicationParameters(String applicationDefinition) 1540;

[0101] In this example, the parameters, containerDefinition andapplicationDefinition, may be implemented in XML format and can bevalidated by a suitable XML schema (see FIGS. 16-17). The returnedICFResult object contains ICFResult.RESULT_CODE_OK inICFResult.getResultCode( ) upon successful operation.

[0102] In another aspect, instrument services may also provide aninterface implementation for a type service provider to retrievespecific container and application parameters, an example of which isshown below:

[0103] ICFResult ICFGetContainerParameters( ) 1550;

[0104] ICFResult ICFGetApplicationParameters ( ) 1560;

[0105] In this example, if the operation is determined to be successful,the returned ICFResult object may be designated to contain an XML stringdefinition that was installed by the application installer using theICFRegisterApplication call. A successful operation results in thereturned ICFResult object containing an XML sample definition. The typeand content of the information provided depends on the provider'simplementation and it will be appreciated that a type service providermay be part of an instrument service provider or a standalone typeservice provider.

[0106] In another aspect, the GUI client 1505 may use the XML containerdefinition to construct a container creator. FIG. 12 illustrates asample snapshot 1600 from a data collection instrument. In this example,the GUI container creator may comprise attributes, such as “ContainerName”, “Plate ID”, “Description”, among others. These attributes may beextracted from the XML container definition registered by theapplication installer. In one aspect, a customized container editor for“Genemapper” may be constructed following execution of the “OK” button1605. In this example the customized container editor may extract columnnames from an XML sample definition registered by application installer.

[0107] In another aspect, container import may be implemented asfunctions commonly used in instruments supported by instrument services.The following FIGS. 13-15 illustrate the “pulling” and “pushing” of alogical container to import the container into a instrument serviceprovider 1710. As shown in FIG. 13, a custom client 1705 may use thefunction subscribeInstrumentEvents( ) to prepare itself to receiveinformation from the ICFStatusEvents( ) and ICFContainerStatusEvents( )functions. Once ready, a custom client 1705 may then useICFRegisterContainerProvider( ) call 1715 to notify the instrumentservice provider (ISP) 1720 that the custom client 1705 is available toprovide the desired container information. This function call mayfurther return a Boolean result to indicate an ISP acknowledgment andfurther indicate if the container import functionality is supported. Theclient 1705 may further use this result code to determine if the ISP1720 supports the selected feature. Subsequently, the ISP 1720 maynotify the Instrument to process the next available container uponreceiving a “start run” command from the user interface component (notshown in Figure). In various embodiments, the ISP 1720 may receive acontainer barcode identifier as the return of processNextContainer( )1725. The ISP may then attempt to locate the container's informationfrom its own database. The flowchart shown in FIG. 14 illustratesdetails for this conditional situation.

[0108] In one aspect, if the desired information 1825 is available fromthe database 1830, the ISP 1720 may schedule a run 1835 for thiscontainer and perform run(s) using this container. If ISP 1720 does notfind the container's information in its database and at least one customclient has registered with the ISP 1720 to provide containerinformation, the ISP 1720 may send out a ICFContainerStatusEvents( )1840 call to the messaging service. A custom client 1705 receives thisevent and uses the importContainer( )function to provide containerinformation to the ISP 1720. When the ISP 1720 finishes the scheduledrun(s) 1835 for this container, a “run completed” notification may besent in the ICFStatusEvents( )function. Subsequently, the custom client1705 may update the status for the container in its database.

[0109]FIG. 15 illustrates how a custom client 1705 can “push” containerinformation to a service provider 1720 to persist in the serviceprovider's database allowing it to be run at a later time. In theexample, the custom client 1720, which may be a GUI that allows user totype or scan a container barcode or other identifier sample information,requests container information from the LIMS system 1930. Once thecontainer information is acquired, the client 1705 may use theimportContainer( )function 1940 to “push” it into ISP 1720.

[0110] In one aspect, the service provider 1720 provides logicalcontainer information by implementing the aforementioned interfacedefinition to provide synchronous service. This service is designed toprovide some of the functionalities illustrated in the use case diagram(FIG. 15) for integrating with a LIMS client 1930. In variousembodiments, an instrument service provider 1720 may implement theinterface according to the function:

[0111] ICFResult importContainer(String plate Text);

[0112] Here the client may provide an XML data string (conforming to thecontainer XML schema) as a parameter for the, call. An ICFResult objectcontaining ICFResult.RESULT_CODE_OK in ICFResult.getResultCode( ) maythen be returned upon a successful operation The service provider mayfurther publish an ICFContainerStatusEvents function when containerinformation is desirable to run or execute a physical container.

[0113] FIGS. 16-20 illustrate various embodiments of XML schema forapplication and container definitions that may be used in implementationof the aforementioned service sets and container creation/utilizationservices. It will be appreciated by one of skill in the art that theseschemas may be readily modified to accommodate new or different datatypes without departing from the scope of the present teachings.

[0114] The aforementioned description of instrument and applicationservices desirably provides a highly configurable and readily modifiablemeans for control and management across different instrument andapplication platforms. Furthermore, these services provide for improvedintegration of sample identification functionality requiring little orno user input.

[0115] In one aspect, the “push”/“pull” functionality described aboveprovides a convenient method for implementing “just in time” sampleidentification and information import functionality wherein a selectedinstrument can obtain information for a particular sample or analysis onan as needed basis rather than storing a large amount of data describingnumerous samples which may or may not be utilized. The just in timefunctionality helps to provide appropriate sample and analysisinformation on an as need basis thereby conserving system resources andproviding for relatively seamless integration of instruments andapplications within the LIMS environment. Additional details of the justin time functionality are described elsewhere.

[0116] Dynamic Loading of User Interface

[0117] In various embodiments, the user interface may be desirablyimplemented in a dynamically loaded manner such that a relativelyconsistent view is maintained for different instrument and applicationtypes. View consistency typically improves the user's ability tointeract with the LIMS system through the user interface as the user maybecome accustomed to a generic application and instrument presentationwherein fields, buttons, and other information is situated in the userinterface in a predicable and uniform manner.

[0118] Additionally, in conventional systems changes in an applicationor instrument may affect the user interface and reconfiguration of theuser interface can take up much time and effort. Modifying or addinginstruments or applications may significantly affect a client sideviewing or interaction application and necessitate recompiling, testing,and shipping of a new/updated vendor side application which must bereinstalled on the client side.

[0119] In various embodiments, to avoid such costly and time consumingprocedures, the present teachings provide means for dynamically loadingof classes and components for instruments and applications. In oneaspect, the client side user interface may utilize a dynamic loadingfunctionality implemented in a programming language such as JAVA whereinvarious instrument and application classes are contained in jars.Additionally, it will be appreciated that the dynamic loading prototypemay be used in other areas of the LIMS system outside of the userinterface to provide a similar dynamic loading functionality.

[0120] In one exemplary implementation of a dynamically loaded userinterface using the JAVA language, an application may be contained in aframe (JFrame) with a pane (Jpanel) contained in the frames. A panel isa view of the application and generally comprises the expectedcomponents for a selected view. In implementing the user interface, aplurality of panels may be selected from a menu list. Typically, when auser launches the user interface application, a frame may be displayed.The user them may select an application menu item and an associatedpanel corresponding to the desired view will be displayed. The panelwill generally contain all the necessary components for that view andcorrespond for example to a selected instrument or data analysisapplication.

[0121]FIG. 21 illustrates one method 4500 for implementing a web-browserbased dynamically loaded user interface implemented using the JAVAlanguage. In state 4505, when a panel displayed in the user interface isselected, an associated panel name may be retrieved in state 4510. Thisname is used as an identifier to identify the appropriate jar fileassociated with it. For example, if a particular panel named “Run3100”is selected, a corresponding file “Run3100.jar” will be looked up instate 4515. Typically, application jars may be stored locally in adirectory on the client side computer. Furthermore, a time stamp may beassociated with the file which is retrieved from the file upon lookup instate 4520. This time stamp may be compared in state 4525 to that of aremotely maintained file stored on a server computer (web server). Ifthe file does not exist or if the times stamp for the file on the clientcomputer is outdated with respect to the remotely maintained file, theclient may retrieve a new/updated file from the server computer in state4530. Once the file has been updated, or if the file on the clientcomputer is not outdated, the file may be executed in state 4535 and theuser interface will display the appropriate information to the user viathe panel.

[0122] In various embodiments, the client/server communications andinteractions may occur in a web/browser based environment. Thus theclient computer may implement the user interface through a web-browserand a connection to a web server may be established using an HTTPprotocol using the clients's IP address as run time input. The timestamp of the panel's jar file may then be retrieved and compared withthe local file's time. If the server's file is newer, it maycache/replace the old file with the new. In the final stage of userinterface loading a class loader may be called to load the classesneeded in the panel to thereby populate the panel with the appropriateinformation to be displayed to the user.

[0123] It will be appreciated that the aforementioned implementation ofa dynamically generated user interface represent but one of manypossible implementations the may be achieved through application of thepresent teachings. As such other implementations and constructions of adynamically generated user interface are considered but otherembodiments of the present teachings. Furthermore, it will beappreciated that other programming languages may be used as a means toimplement the user interface and the user interface may further beconstructed as a standalone application without the requirement of a webbrowser.

[0124] Although the above-disclosed embodiments of the present inventionhave shown, described, and pointed out the fundamental novel features ofthe invention as applied to the above-disclosed embodiments, it shouldbe understood that various omissions, substitutions, and changes in theform of the detail of the devices, systems, and/or methods illustratedmay be made by those skilled in the art without departing from the scopeof the present invention. Consequently, the scope of the inventionshould not be limited to the foregoing description, but should bedefined by the appended claims.

[0125] All publications and patent applications mentioned in thisspecification are indicative of the level of skill of those skilled inthe art to which this invention pertains. All publications and patentapplications are herein incorporated by reference to the same extent asif each individual publication or patent application was specificallyand individually indicated to be incorporated by reference.

What is claimed is:
 1. A system for providing a graphic user interfacefor a biological laboratory having a plurality of biological processinginstruments adapted to process a plurality of biological samples, thesystem comprising: an information component for instruments thatincludes information about the plurality of the biological processinginstruments, wherein the information for a given instrument comprises alist of the instrument's parameters that can be monitored and a list ofthe instrument's parameters that can be controlled; and an interfaceapplication that generates the graphic user interface based on theinformation for one or more of the instruments wherein the interfacethus generated is populated according to at least a portion of theinstrument's monitor and control parameters thereby allowing theinterface application to generate different interfaces based on a singleadaptable template interface.
 2. The system of claim 1, wherein thegraphic user interface for a given instrument allows a user to monitorand control the instrument.
 3. The system of claim 1, wherein theinterface application uses the information about the plurality ofinstruments to generate an instrument management graphic user interfacethat lists the plurality of instruments available for use.
 4. The systemof claim 1, further comprising an information component for samples thatincludes information about the plurality of biological samples whereinthe samples' information component allows the interface application togenerate adaptable graphic user interfaces based on the samples'information.
 5. The system of claim 4, wherein the interface applicationuses the information about the plurality of biological samples togenerate a sample management graphic user interface that lists thesamples in the biological laboratory.
 6. The system of claim 5, whereinthe sample and instrument information are combined to allow theinterface application to generate a study management graphic userinterface.
 7. The system of claim 6, wherein the graphic user interfaceis adapted to allow a user to plan a manner in which data is takenduring a run.
 8. The system of claim 1, further comprising aninformation component for an analysis module that analyzes the data fromone or more biological processing instruments wherein the analysismodule's information component allows the interface application togenerate adaptable graphic user interfaces based for viewing results ofthe analyzed data.
 9. The system of claim 1, wherein the plurality ofbiological processing instruments includes a sample storage device. 10.The system of claim 1, wherein the plurality of biological processinginstruments includes a sample transferring robotics device.
 11. Thesystem of claim 1, wherein the plurality of biological processinginstruments includes a thermalcycler device.
 12. The system of claim 1,wherein the plurality of biological processing instruments includes amass spectrometer.
 13. The system of claim 1, wherein the plurality ofbiological processing instruments includes a sequencer device.
 14. Thesystem of claim 1, wherein the plurality of biological processinginstruments includes an electrophoresis device.
 15. The system of claim1, wherein the plurality of biological processing instruments includesan array device.
 16. The system of claim 1, wherein the plurality ofbiological processing instruments includes an analysis computing device.17. The system of claim 1, wherein the plurality of biologicalprocessing instruments includes a data storage device.
 18. The system ofclaim 1, wherein the instrument component is part of an instrumentdirectory.
 19. The system of claim 1, wherein the graphic user interfaceis based on a web browser.
 20. The system of claim 1, wherein theinterface application is dynamically induced to generate a graphic userinterface corresponding to an added instrument.
 21. The system of claim20, wherein the dynamically generated graphic user interfacecorresponding to the added instrument includes one or more protocolsthat can be provided by the added instrument.
 22. A method of generatinga graphic user interface for a biological laboratory having a pluralityof biological processing instruments adapted to process a plurality ofbiological samples, the method comprising: receiving a request for agraphic user interface; obtaining information associated with therequested graphic user interface; and generating the requested graphicuser interface by populating a template graphic user interface based onthe information obtained.
 23. The method of claim 22, wherein receivingthe request comprises receiving a request for a graphic user interfacefor one or more biological processing instruments.
 24. The method ofclaim 23, wherein obtaining information comprises obtaining informationabout the one or more biological processing instruments from aninstrument directory.
 25. The method of claim 22, wherein receiving therequest comprises receiving a request for a graphic user interface forone or more biological samples.
 26. The method of claim 25, whereinobtaining information comprises obtaining information about the one ormore biological samples from a sample list.
 27. A control system for abiological laboratory having a centralized user interface that providesmonitoring and coordination functionality directed towards the operationof a plurality of laboratory components, the centralized user interfacecomprising: an instrument information acquisition component thatacquires information about the plurality of laboratory components,wherein the information for a selected laboratory component comprisesmonitoring and control parameters; and an instrument interfacegeneration component that generates a user interface using an adaptableinterface template that is populated with at least a portion of theinformation acquired by the instrument information acquisition componentso as to provide a means for selectively generating laboratory componentinterfaces using the information associated with one or more of thelaboratory components.
 28. The system of claim 27, wherein the adaptableinterface template used to generate the user interface receives theinformation for a selected laboratory component and automaticallyassociates one or more presentation fields with information directedtowards instrument monitoring.
 29. The system of claim 27, wherein theadaptable interface template used to generate the user interfacereceives the information for a selected laboratory component andautomatically associates one or more input fields with informationdirected towards instrument control.
 30. The system of claim 27, whereinthe instrument interface generation component receives the informationfrom the instrument information acquisition component and determines thecurrent state of operation for one or more selected instruments which isthereafter integrated into the user interface.
 31. The system of claim27, wherein the instrument interface generation component receives theinformation from the instrument information acquisition component anddetermines the availability of one or more selected instruments which isthereafter integrated into the user interface.
 32. The system of claim27, wherein the instrument interface generation component receives theinformation from the instrument information acquisition component anddetermines a current sample or data set operated on by one or moreselected instruments which is thereafter integrated into the userinterface.
 33. The system of claim 27, wherein the instrumentinformation acquisition component further provides means for determininga current sample inventory which is thereafter integrated into the userinterface by the instrument interface generation component.
 34. Thesystem of claim 27, wherein the user interface is based on a webbrowser.
 35. The system of claim 27, wherein the instrument interfacegeneration component is dynamically induced to generate a user interfacecorresponding to an added instrument.
 36. The system of claim 35,wherein the dynamically generated user interface corresponding to theadded instrument includes one or more protocols that can be provided bythe added instrument.